See #32683 (comment)

As I need to extend Checkstyle's import-control.xml, would it be fine to add a top-level allow statement close to:

or should I define a more fine-grained rule, restricting it to the following packages?

• org.springframework.boot.test.context.assertj
• org.springframework.boot.test.json

would it be fine to add a top-level allow statement close to

Yep. The intention is to restrict only to certain AssertJ entry point and this is one of them so I think that's ok.

@scordio how is it going, anything I can do to help?

Apologies, life happened and this fell off my radar! 🤦

If not in a rush, I'm happy to continue on it over the weekend.

Thanks, @scordio. There's no rush.

When building the project locally, I get two NullAway errors on :core:spring-boot:compileJava:

/Users/stefano/Projects/spring-boot/core/spring-boot/src/main/java/org/springframework/boot/context/properties/bind/ValueObjectBinder.java:424: error: [NullAway] Method returns @Nullable String @Nullable [], but overridden method returns String [], which has mismatched type parameter nullability
		public @Nullable String @Nullable [] getParameterNames(Constructor<?> constructor) {
		                                     ^
    (see http://t.uber.com/nullaway )

/Users/stefano/Projects/spring-boot/core/spring-boot/src/main/java/org/springframework/boot/logging/structured/StructuredLogFormatterFactory.java:240: error: [NullAway] referenced method returns @Nullable, but functional interface method java.util.function.Function.apply(T) returns @NonNull
					ArgumentResolver.from(StructuredLogFormatterFactory.this.instantiator::getArg));
					                      ^
    (see http://t.uber.com/nullaway )

but the CI seems fine 🤔

@scordio you need Java 24 to build the project

I've moved to this to 4.x as we're approaching RC1 but not worries either way. Thanks for your efforts!

Thanks, @wilkinsona! I'll address them later in the day.